1. Field of the Invention
This invention relates to asynchronous inbound transactions and more particularly relates to asynchronous inbound transactions from an SAP application using a service oriented architecture.
2. Description of the Related Art
Communication over the Internet and similar computer networks where components and communication pathways have a tendency to change more easily lends itself to loosely coupled connections using service oriented architecture (“SOA”). Loose coupling describes a relationship between two or more computer systems exchanging data where each end of a communication or transaction makes its requirements explicit and makes few assumptions about the other end. Loose coupling lends itself to replaceable components within or at either end of a communication pathway.
SOA is a perspective of software architecture where services are used to support the requirements of software users. Nodes in an SOA environment make resources available to other participants in the network as independent services that a participant may use in a standardized way. Services interoperate based on a formal definition, or contact, which is independent from the underlying platform and programming language. Software components are reusable and replaceable because the interface is standards-compliant and independent of the underlying implementation of the service. SOA can support integration with a complex enterprise information system (“EIS”).
An EIS is a complex computing system that supports a high quality of service, usually dealing with large volumes of data, and is capable of supporting a large organization, such as a banking system or a large retail chain. Examples of enterprise information systems are Oracle®, PeopleSoft®, and SAP®. SAP is a program used for managing business information, customer relations, supply chains, human resources, and product lifecycles, among other services. SAP and other enterprise information systems may exchange information with other enterprise information systems. Integration brokers facilitate information exchange. An example of an integration broker is the WebSphere® Process Server (“WPS”). An integration broker includes an adapter to interface with an enterprise information system, such as SAP, with another enterprise information system or for a client application.
An important form of communication between enterprise information systems is that of a transaction. A transaction involves a related collection of operations. A transaction has the properties of atomicity, consistency, isolation, and durability. Atomicity means that all of the operations are applied or none of them are applied. For example, in a financial transaction, a credit to one account and debit to another account must both be applied or neither applied. Consistency means that the transaction represents a correct transformation of the application state. For example, in a financing, the sum of all asset accounts must equal the sum of all liabilities. Isolation means that the effects of one transaction do not affect other transactions executing concurrently. Durability means that once a transaction successfully completes, changes to the application will survive failures. This is usually accomplished through backing up data and error recovery.
Typically a transaction involving two or more resource applications requires a verification process called a two-phase commit. A two-phase commit involves a first step of sending the required data and accompanying instructions to each resource application for execution. Each resource application executes the required part of the transaction and logs the transaction. Each resource application then typically replies to a resource manager with an agreement message if the transaction succeeded or an abort message. In an asynchronous environment, the agreement message may simply be an acknowledgement that the resource application has successfully received the data for execution. If all the resource applications return a success message, then the resource manager can send a commit message and the resource applications release all locks on the transaction, finalize the changes, and send an acknowledgment to the resource manager. In case of failure of any part of the operation, the resource manager signals a rollback and all operations are undone and the affected accounts are restored to the state prior to the operation.
Where only one resource application is part of a transaction, a similar procedure may be used to ensure once only delivery of the transaction. Such a transaction may be called a local transaction. A local transaction does not involve a two-phase commit, but may include a commit step after execution of the transaction in the resource application. For one or more resource applications, the resource applications may be running on various enterprise information systems loosely coupled through an integration broker and complying with the SOA.
One method for communicating with an SAP application is to use a form of the remote function call (“RFC”) protocol. Transactional RFC (“tRFC”) protocol is used for asynchronous transactions. SAP applications may use the application link enabling (“ALE”) interface for processing asynchronous transactions. Transactions may be inbound or outbound. Inbound transactions with an SAP application are from the perspective of an adapter in communication with the SAP application and cover transactions pushed to the adapter from the SAP application. Adapters available in the present state of the art for handling inbound asynchronous transactions from an SAP application in a Service Component Architecture (“SCA”) do not support J2EE Connector Architecture (“JCA” or “J2C”) calls using Service Data Objects (“SDO”) by way of extended architecture (“XA”) transactions to achieve guaranteed once only delivery or two-phase commit. Adapters in the current state of the art handling inbound asynchronous transactions from SAP applications also do not support multiple SAP applications.
From the foregoing discussion, it should be apparent that a need exists for an apparatus, system, and method that handle inbound asynchronous transactions using the tRFC protocol from one or more SAP applications and allowing J2C inbound communication to one or more endpoints using XA transactions. Beneficially, such an apparatus, system, and method would provide an event recovery mechanism, provide for guaranteed once only delivery, and convert an intermediate document (“IDoc”) or IDoc packet from an SAP application into one or more service data objects (“SDO”) that include one or more business objects (“BO”) for delivery to one or more endpoints.